package com.linxchong.security.filter;

import com.marcosbarbero.cloud.autoconfigure.zuul.ratelimit.config.repository.DefaultRateLimiterErrorHandler;
import org.springframework.stereotype.Component;

/**
 * @Author:linchong
 * @CreateTime:2020-07-15 13:08
 * @Description:自定义限流异常处理
 */
@Component
public class MyRateLimitErrorHandler extends DefaultRateLimiterErrorHandler {


	@Override
	public void handleError(String msg, Exception e) {
		super.handleError(msg, e);
	}

	/*
	 *  前两个方法和数据的限流存取有关，一般不重写
	 *  向数据库存储当前的限流信息时出错的处理
	 *   public void handleSaveError(String key, Exception e) {
	 *         log.error("Failed saving rate for " + key + ", returning unsaved rate", e);
	 *     }
	 *
	 *  在数据库中读取限流信息时出错的处理
	 *   public void handleFetchError(String key, Exception e) {
	 *         log.error("Failed retrieving rate for " + key + ", will create new rate", e);
	 *     }
	 *
	 *  限流过程中发生错误，一般重写它，实现自己的逻辑处理，添加日志，返回额外的信息
	 *   public void handleError(String msg, Exception e) {
	 *         log.error(msg, e);
	 *     }
	 *
	 *
	 */

	/*
	 *  网关上做限流存在的问题：
	 * 1.耦合问题，如根据优惠券的类型，对某个请求做限流，如果后面的业务逻辑改变，网关代码也会随着改变，重写部署，
	 * 如优惠券类型多了一个，所以，网关应该做到不管业务逻辑怎么变，我的网关不能跟着变
	 * 2.限流的数量问题，网关只能处理在微服务的外部进来的请求，并不处理微服务之间的调用。
	 * 如有a、b两个服务，限流都是100/s,b服务业务中会调用A服务，一百个请求分别到a和b，没超过，都可以通过，
	 * 但是100个到b的请求会触发100个到a的请求，a同时处理200个请求，a可能挂掉，所以网关层做限流是无法微服务之间
	 * 的流量的，所以一般情况下，网关不做细粒度的限流，网关上主要是对硬件的处理能力做限流，如多个tomcat,每个大约可以处理
	 * 多少个并发请求，所以user,role等的限流配置不建议做，业务改变，网关就需要重新部署
	 */












}
